home *** CD-ROM | disk | FTP | other *** search
-
- C-BBS V7.20j (Multi-Port) for the AMIGA (Kickstart V1.3 and V2.0)
- Multi-Port Documentation (DRAFT)
- Copyright VE5VA 13th April 1993
-
-
- BEFORE you try to run multiple ports make a BACKUP of EVERYTHING. I will
- not be held responsible for the loss of any data. Use this version at your
- own risk!
-
-
- I have finally solved the problem of mediating between multiple
- processes all trying to read or write the mail.dat, user.dat and bid.mb
- files. I have added code that uses semaphores to control access to each
- file. When running multiple copies of 'mb' you still only need ONE copy
- of the following files:
-
- mail.dat
- user.dat
- config.mb
- bid.mb
- help.mb
- info.mb
- states.mb
- reject.btn
-
-
- Other files require a separate copy for each port, but in order to
- allow a single-port system to be run without any changes, the names of the
- files for port A do not change from what is specified in the config.mb
- file. For example, the log.mb file is still called log.mb on port A, but
- on all other ports the system changes the name so that the suffix is the
- port letter. Therefore, the 'mb' that runs on port D will create and
- maintain a log file called log.d. Most of the files such as the log file
- and calls.mb are created by the system with correct names if they are not
- present when the program starts. There are only a few that the user must
- create. All the following files require multiple copies and will be
- created in the same way as shown in the table below.
-
- Port -> A B C .......
-
- log.mb log.b log.c etc.
- mon.mb mon.b mon.c
- calls.mb calls.b calls.c
- tnc.on tnc.on.b tnc.on.c
- tnc.off tnc.off.b tnc.off.c
- talk.on talk.on.b talk.on.c
- talk.off talk.off.b talk.off.c
-
-
- The first three in the list are created automatically by the system.
- The remaining files must be created by the user if the files are needed
- (e.g. you probably won't have talk.on or talk.off files for all the
- ports).
-
-
- The bulletin.a, bulletin.b etc. files are unchanged and are created
- as needed by the sysop.
-
-
- When you start up each copy of 'mb' it must have the -pP argument on
-
-
- it to specify which port (P) the program is to use. If it is not specified
- then the port letter P defaults to port A (see the example startup script
- below).
-
-
- The config.mb file does not change and all ports are specified in the
- one copy of config.mb. You tell a specific copy of 'mb' which port it is
- to use by specifying the port letter as an argument when 'mb' is started.
- It then reads only that port and port 'Z' from the port description list.
- To simplify the startup procedure, I have modified the code so that you
- can specify the device unit number and name, in that order, at the end of
- the port specification line. The unit number defaults to zero and the name
- defaults to "serial.device". You can still use the -u and -n arguments if
- you wish. The content of the config.mb file will override the arguments if
- they are both given. Here is an example of the beginning of a config.mb
- file describing two ports:
-
- A123UDRT 600 20 600 100 20 4 5 8 15 0 serial.device
- -> 145.01 Mhz.
- B123UDRT 600 20 600 100 20 4 15 8 15 1 serial.device
- -> 443.71 Mhz
- ZCE#D 300 10 600 100 10 0 27 8 0
- -> Stations Connected
- *** EOF
-
- Note that in V7.2, the console port is now port Z (not port L). When each
- copy starts up, it creates a public port which contains the name of the
- port so that you can start up your system in an orderly fashion. For
- example, port B will create the port name "CBBS-B" and your startup script
- can use waitport to wait until this name is created before it starts up
- the next port. E.g.
-
- ; This script is used with the multi-port version of 'mb'.
- ; An example of starting up a 3 port system. I have omitted details like
- ; specifying the window position and size using the -w argument.
- ; This example assumes that the port unit and device names are specified
- ; in config.mb
- ;
- ; Always delete T:mbuser.index at startup if it exists.
- if exists T:mbuser.index
- delete T:mbuser.index
- endif
- ;
- ; Change to the directory containing C-BBS
- ;
- cd work:cbbs
- ;
- ; Start locker
- run locker
- waitport VE5VA-LOCK 20
- ;
- ; I don't need the -z argument when running mb because it is set with the
- ; setenv command in my s:startup-sequence.
- ; Default to port A on startup
- ;
- run mb
- waitport CBBS-A 20
- ; Specify port B
- run mb -pB
- waitport CBBS-B 20
-
-
- ; and port C
- run mb -pC
- waitport CBBS-C 20
- ; and just as an example lets get sysop going too
- run sysop
- waitport CBBS-1 20
-
-
- Note that at the beginning, the script looks for the file
- T:mbuser.index and if it exists it is deleted. In order to handle multiple
- accesses to the user file, I had to change the way in which it checks to
- see if it knows a specific user callsign. In the original C-BBS, each copy
- of 'mb' kept its own list of callsigns in a table. This causes a problem
- because if the user file changes size then every process must recreate
- their internal table. To simplify things, I changed the code so that the
- table is stored in the file T:mbuser.index which is accessible to all
- processes. The first process to start up (usually port A, but it doesn't
- have to be) will find that the index is not in ram so it will get a lock
- on the user file, create the index and then release the lock. The other
- processes will find that the index is already there and won't try to
- recreate it. The file is only modified if a user is added to, or deleted
- from, the user.dat file. In this case, the process making the change will
- also change the index. The other processes will find out that the file has
- changed when they try to access the lock on the file and this causes them
- to close the file and reopen it so that they see the changes that have
- been made. This is essentially how the locking is handled with the
- mail.dat too except that it doesn't need an index file - it is the index.
- The only other file that required locking was the bid.mb file.
-
-
- The forwarding process has been modified slightly to prevent multiple
- copies of 'mb' trying to do a forward on the console port 'Z' at the same
- time. Only the port A process will do forwarding for the console and
- therefore there MUST be a port A process if you want forwarding for port Z
- to be done.
-
-
- The locking which prevents 'GM', 'GU' and 'GR' from being executed
- while any other process is active is still incorporated in the program. If
- you set a forwarding script so that a 'GM' is done automatically at 3am it
- will only succeed if nobody else is logged in at the time AND THIS
- INCLUDES THE SYSOP PROCESS which must be idle when the 'GM' is attempted.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-